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(57) The present invention provides a method, sys- 
tem and apparatus for managing data flow over an open 
system interconnection type network (10) which in- 
cludes a physical layer (12) and a media access control 
layer (146). The invention implements a plurality of op- 
erating modules (315) each enabling a respective media 
access control layer operating function in which at least 



a portion of the operating modules are implemented in 
software. The invention further implements a host inter- 
face module (305) for communication between a host 
processor and the media access control layer, a physi- 
cal layer interface module (31 0) for communication be- 
tween the physical layer and media access control layer, 
and an inter-module programming interface for commu- 
nications between respective operating modules. 
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Description 

[0001] The invention is related to and claims priority 
under 35 USC 1 1 9(e) (1 ) from the following co-pending 
U.S. Provisional Patent Applications: serial number 
60/1 72,51 6 by Lu et al., entitled A Programmable Multi- 
standard MAC Architecture, and filed on December 17, 
1999; and serial number 60/1 72,541 by Lu et al., entitled 
DSP Core/PHY Interface Specification, and filed on De- 
cember 17, 1999. All of the aforementioned patent ap- 
plications are hereby incorporated by reference. 

BACKGROUND OF THE INVENTION 

Technical Field of the Invention 

[0002] The present invention relates generally to the 
field of communication networks and, more particularly, 
to a programmable Media Access Control implementa- 
tion method and architecture. Background of the Inven- 
tion 

[0003] Figure 1 shows a diagrammatic representation 
of an open systems interconnection (OS I) layered mod- 
el 10 developed by the International Organization for 
standards (ISO) for describing the exchange of informa- 
tion between layers in communication networks. The 
OSI layered model 10 is particularly useful for separat- 
ing the technological functions of each layer, and there- 
by facilitating the modification or update of a given layer 
without detrimentally impacting on the functions of 
neighboring layers. At a lower most layer, the OSI model 
1 0 has a physical layer or PHY layer 1 2 that is respon- 
sible for encoding and decoding data into signals that 
are transmitted across a particular medium. Above the 
PHY layer 12, a data link layer 14 is definedfor providing 
reliable transmission of data over a network while per- 
forming appropriate interfacing with the PHY layer 12 
and a network layer 16. The Network layer 1 6 is respon- 
sible for routing data between nodes in a network, and 
for initiating, maintaining and terminating a communica- 
tion link between users connected to the nodes. A 
Transport layer 18 is responsible for performing data 
transfers within a particular level of service quality. A 
Session layer 20 is generally concerned with controlling 
whenusers are able to transmit and receive data. A 
Presentation layer 22 is responsible for translating, con- 
verting, compressing and decompressing data being 
transmitted across a medium. Finally, an Application 
layer 24 provides users with suitable interfaces for ac- 
cessing and connecting to a network. 
[0004] The IEEE Local Area Network (LAN) stand- 
ards divide the Open System Interconnection (OSI) data 
link layer into two sub-layers as illustrated in Figure 1 : 
the Media Access Control (MAC) 14b and the Logical 
Link Control (LLC) 14a. The LLC layer 14a is generally 
a software function that is responsible for attaching con- 
trol information to the data being transmitted from net- 
work layer 16 to MAC layer 14b. The MAC layer 14b 



deals with the media access techniques utilized to con- 
trol the access to a shared physical medium 26. The 
MAC layer 14b is primarily responsiblefor controlling the 
flow of data over a network, ensuring that transmission 

5 errors are detected, and ensuring that transmissions are 
appropriately synchronized. Token Ring and Ethernet 
are two legacy implementations of a MAC layer which 
use different methods to share the physical media. 
These two MAC types are typically implemented in an 

10 integrated circuit (IC) hardwired because of its technol- 
ogy maturity. 

[0005] With technology development in the broad- 
band communication area, bigger and faster data com- 
munication pipes are being established from homes and 

15 small offices to network servers and the Internet. The 
LAN technology has been extended to cover the home 
and small office environmentusually called Home Net- 
working. The most prevalent high-speed home network- 
ing technologies in the industry are: HPNA 2.0/1 .0, leg- 

20 acy Ethernet and 802.11 wireless LAN. These three 
technologies use a shared media access control meth- 
od to access the physical layer phone wires, Ethernet 
cables and wireless media. 

[0006] Although the MACS of these home LANs share 

25 some common features, each MAC maintains respec- 
tive specialties. HPNA 1 .0 and Ethernet MAC both use 
standard IEEE 802.3 CSMA/CD (Carrier Sense Multiple 
Access with Collision Detection), which uses a binary 
exponential backoff algorithm to defer its transmission 

30 when media is busy. HPNA2.0 MAC added a Distributed 
Fair Priority Queuing (DFPQ) deferring algorithm in ad- 
dition to the CSMA/CD to provide the Quality of Service 
(QOS) guarantee at the physical layer. The HPNA 2.0 
also generally allows two types of MAC architectures: a 

35 CSMA/CD with DFPQ type MAC and a standard 802.3 
MAC with DFPQ Enhanced MAC (EMAC) or two layer 
MAC. Each has its advantages and disadvantages. 
IEEE 802.11 wireless LAN uses Carrier Sense Multiple 
Access with Collision Avoidance (CSMA/CA) and NAV 

40 (Network Access Vector) technologies in the MAC layer 
for the assumption that each station cannot be guaran- 
teed to be able to detect other stations in the wireless 
communications network. 

[0007] In addition to the current requirements of the 
45 different MAC architectures and MAC implementations 
for various standards, development of the new home 
LAN technology, for example, is causing existing MAC 
standards to evolve and/or new MAC standards to 
emerge. Therefore, it would be advantageous to provide 
50 a new software based or programmable MAC imple- 
mentation architecture which would speed up MAC im- 
plementation development, MAC/PHY and MAC/host 
integration, enable multiple MAC implementations, and 
increase MAC portability for different applications and 
55 platforms. 
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SUMMARY OF THE INVENTION 

[0008] The present invention achieves technical ad- 
vantages as a method, system and apparatus for man- 
aging data flow over an open system interconnection 
type network which includes a physical layer and media 
access control layer. The invention implements a plural- 
ity of operating modules each enabling a respective me- 
dia access control layer operating function in which at 
least a portion of the operating modules are implement- 
ed in independent software. The invention further imple- 
ments a host interface module for communication be- 
tween a host processor and the media access control 
layer, a physical layer interface for communication be- 
tween the physical layer and media access control layer, 
and an inter-module programming interface for commu- 
nication between the respective operating modules. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0009] For a more complete understanding of the 
present invention, reference is madetothefollowing de- 
tailed description taken in conjunction with the accom- 
panying drawings wherein: 

Figure 1 illustrates an open systems interconnec- 
tion (OSI) layered model; 

Figure 2 shows a block diagram of a modulized soft 
MAC architecture in accordance with an embodi- 
ment of the present invention; 
Figure 3 shows a block diagram of another embod- 
iment of a modulized soft MAC architecture in ac- 
cordance with the present invention; 
Figure 4 illustrates a Queue Descriptor and associ- 
ated Data Buffers in accordance with an embodi- 
ment of the present invention; 
Figure 5 illustrates a control signal or message ex- 
change by a host and MAC controller supporting 
Queue Manager Protocol operation in accordance 
with an embodiment of the present invention; 
Figure 6 illustrates a preferred embodiment of a 
HomePNA digital chip-set in accordance with an as- 
pect of the present invention; 
Figure 7 illustrates an MM extended MAC/PHY in- 
terface signals in accordance with an aspect of the 
present invention; 

Figure 8 shows relative interface signal timing dur- 
ing frame transmission with no collisions; 
Figure 9 shows relative interface signal timing dur- 
ing frame reception without error; 
Figure 1 0 shows relative interface signal timing dur- 
ing frame transmission with a collision; 
Figure 1 1 shows relative interface signal timing dur- 
ing frame reception with errors; 
Figure 12 shows a tabulated MAC/PHY interface 
register set accessible to the MAC controller in ac- 
cordance with an aspect of the present invention; 
Figure 1 3 shows a tabulated bit assignment set for 



the control register of the MAC/PHY interface 
shown in Figure 12; 

Figure 1 4 shows a tabulated bit assignment set for 

the status register shown in Figure 12; 
5 Figure 1 5 shows a tabulated bit assignment set for 

the Interrupt Mask register shown in Figure 12; 

Figure 1 6 shows a tabulated bit assignment set for 

the Interrupt Status register shown in Figure 12; 

Figure 1 7 shows a tabulated bit assignment set for 
10 the PHY Management Control register shown in 

Figure 12; 

Figure 1 8 shows a tabulated bit assignment set for 
the PHY Management Status registershown in Fig- 
ure 12; 

15 Figure 19 shows a tabulated MAC/PHY interface 

register set accessible to the PHY in accordance 
with an aspect of the present invention; 
Figure 20 shows a tabulated bit assignment set for 
the Signal Control registershown in Figure 19; 
20 Figure 21 shows a tabulated DSP/PHY interface 
register set accessible to the DSP in accordance 
with an aspect of the present invention; 
Figure 22 shows a tabulated DSP/PHY interface 
register set accessible to the PHY in accordance 
25 with an aspect of the present invention; 

Figure 23 illustrates exemplary MAC systems using 
a modulized soft MAC architecture; and 
Figure 24 illustrates exemplary implementations of 
HPNA 2.0 MAC architectures. 

30 

DETAILED DESCRIPTION OF THE INVENTION 

[0010] The numerous innovative teachings of the 
present application will be described with particular ref- 

35 erence to the presently preferred exemplary embodi- 
ments. However, it should be understood that this class 
of embodiments provides only a few examples of the 
many advantageous uses and innovative teachings 
herein. In general, statements made in the specification 

40 of the present application do not necessarily delimit any 
of the various claimed inventions. Moreover, some 
statements may apply to some inventive features, but 
not to others. 

[001 1] Referring now to Figure 2 there is illustrated a 
45 soft MAC 210 in accordance with a preferred embodi- 
ment of the present invention. The soft MAC 21 0 is di- 
vided into the following modules and each module pro- 
vides standard APIs for inter-module communication 
purposes: MAC transmitter module 220; MAC receiver 
50 module 230; Deference algorithm module 240; MAC 
statistical information maintenance module 250; Other 
management function module 260; and MAC utility 
module 270. 

[001 2] The MAC transmitter module 220 enables pre- 
55 processing of the packet transmission to the PHY layer 
which includes packet framing, transmit condition 
checking based on the output of the deference algorithm 
i.e., media is busy. 
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[0013] The MAC receiver module 230 enables pre- 
processing of the packet received from the PHY layer 
which includes packet recognition, packet format check- 
ing, error checking, statistical information report to the 
statistical maintenance module 250. 
[0014] The deference algorithm module 240 imple- 
ments the backoff algorithm when the media is busy and 
the transmitter has to delay its current packet transmis- 
sion to a later time. A typical/standard deference algo- 
rithm includes BEB (Binary Exponential Backoff) used 
in the 802.3 MAC. 

[0015] The MAC statistical maintenance module 250 
stores all the needed statistical data for the MAC layer. 
Typical statistical information includes number of pack- 
ets transmitted/received, number of bytes transmitted/ 
received, number of packets received with errors, 
number of packets transmitted with deferring, etc.. 
[0016] The other management function module 260 
coordinates the functioning of each individual modules 
such as scheduling and added Quality of Service sup- 
port in the MAC layer which is not included in the defer- 
ence algorithm module 240. 

[001 7] The MAC utility module 270 enables the func- 
tions that are being used in more than one module in 
the MAC, such as error checking/calculation, to be 
shared among multiple MAC modules. 
[001 8] Splitting MAC software into the above modules 
with standard API definitions enables certain MAC func- 
tions to be moved off-chip into other processors or hard- 
ware as is necessary for a specific implementation to 
meet cost or speed requirements, for example. The sep- 
arate MAC software module architecture further ena- 
bles combining the similar functionality, of devices im- 
plementing differing MAC standards, in a single module. 
Thus, in the home networking area, for example, the 
Deference Algorithm module 240 implements BEB on 
HPNA 1.0 or Ethernet 802. 3 MAC, DFPQon HPNA2.0. 
and CSMA/CA and NAV on 802.11 MAC implementa- 
tions. 

[0019] Additionally, many of the different standard 
MAC implementations share the same utility functions 
(such as cyclic redundancy checks, randomizers, ad- 
dress filtering, etc.) which can be implemented in the 
utility module 270. 

[0020] Further, special management functions for 
each of the aforementioned MAC implementations can 
be implemented in the separate Other Management 
Module 260 to increase portability. For example, a 
802.11 MAC contains special station management func- 
tions such as authentication, association, roaming, and 
other management functions known in the art. 
[0021] The MAC modules can be dynamically down- 
loaded from other devices. The download of the soft- 
ware MAC modules are based on a specific application 
platform., such as, downloaded from a FLASH in the 
system or from host controller, etc. 
[0022] Referring now to Figure 3 there is illustrated a 
block diagram of an implementation ofthemodulizedsoft 



MAC together with part of the PHY in a single DSP proc- 
essor in accordance with the present invention. The il- 
lustrated soft MAC architecture 300 contains the follow- 
ing components in addition of the core MAC software 
5 modules described before: A Host/MAC Interface 305 in 
which a queue manager is defined to manage the frame 
data and control information communication between a 
host and the MAC layer through various hardware bus 
interfaces such as PCI, for example; a MAC/PHY Inter- 
face 31 0 in which interface communication is defined to 
manage an enhanced Mil interface between the MAC 
layer and the PHY layer; a modulized soft MAC 315 or 
a modular organized software architecture, which con- 
tains multiple MAC layer software modules 320, 325, 
330, 335, 340 as described before; an Inter-MAC com- 
munication protocol which is a simplified communication 
protocol/ PA Is (not shown) for enabling communication 
between the MAC software modules which may be split 
between multiple processors or between hardware and 
software; and an optional scheduler 345 used to sched- 
ule MAC module processes and MAC and PHY layer 
processing. 

[0023] Further, for a MAC architecture used to imple- 
ment part of or the whole PHY layer operating functions 
(i.e., PHY processing software and PHY hardwired cir- 
cuits), it is preferred to have a resource management 
scheduler 345 implemented with this MAC architecture 
to guarantee that the processing of the PHY layer func- 
tions do not interrupt the MAC layer module functioning. 
Also, a scheduler can be used to handle different MAC 
modules running at different priorities. 
[0024] In some embodiments, the modulized soft 
MAC 315 is implemented in a microprocessor or MAC 
controller 300. For MAC implementations of HomePNA 
2.0/1 .0 and 802.11 , the MAC controller 300 supports re- 
al-time response at jis resolution (for example, the in- 
terrupt latency is less than 1jis), 

[0025] In a specific MAC, the timing control for a def- 
erence algorithm is undercertain resolution, i.e., several 
microseconds for HomePNA MAC. This requires the 
software implementation of the deference module in a 
micro-controller to be able to achieve the deterministic 
timing response at microseconds resolution. A CPU that 
does not meet this requirement, will not be able to sup- 
port the MAC software implementation. 
[0026] The MAC module 300 also supports at least 
two levels of processing priority (such as IRQ level and 
normal processing level), since multiple modules are ex- 
ecuting "in parallel" under the MAC layer. For example, 
while the transmitter modules are transmitting, the def- 
erence module is running "in parallel" to check if media 
is busy, if busy then deferring, and the receive module 
is also checking the packet receive condition. In order 
to guarantee the "parallel" processing, at least two lev- 
els of priority are supported to provide "critical" versus 
"noncritical' processing. 

[0027] AFE l/F 360 is the interface between the phys- 
ical layer PHY and the analog front end which converts 
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analog signals into digital signals or vice versa. 
[0028] DSP l/F 355 is the interface to allow the part 
of the PHY layer functions implemented inside a DSP 
to interface with the hardware PHY. 
[0029] The MAC controller 300 further includes, in 
some embodiments, an associated timer (not shown) 
with interrupt atjis counting/timing resolution (for exam- 
ple, it can periodically generate interrupts every 1 jis if 
necessary)- The timer can be included off-chip of as an 
external timer circuit. 

[0030] For some implementations in which PHY layer 
processing coexists in the MAC controller 300, the PHY 
processing is included in a PHY processing software 
module 350. Further, in some embodiments, the MAC 
controller 300 is a DSP, for example, for those imple- 
mentations which include PHY processing and mod- 
ulized soft MAC modules on the same processing chip. 
The MAC controller 300 has MIPS and on-chip memory 
(both program memory and data memory) to support 
software MAC functions and DSP functions if applica- 
ble. The associated clock rate is synchronized with an 
external PHY layer clock rate if applicable. 
[0031] The MAC/PHY interface 310 includes: the 
hardware interface and the MAC/PHY software inter- 
face module which resides in the MAC controller 300 
and manages the hardware interface. The hardware in- 
terface between the MAC and PHY is defined as a Mil 
or a MM enhanced interface specification. The MM Inter- 
face is specified by IEEE 802.3. The MAC/PHY interface 
310 can be implemented using the standard MM when 
it is possible. However, an enhanced Mil can be used 
to accommodate additional signal lines and/or increase 
the data bus width for implementation which include 
PHY processing and soft MAC modules on the same 
processing chip. The enhanced MM interface for a 
HomePNA MAC/PHY is described in more detail in fol- 
lowing sections of the present Detailed Description. An 
independent MAC/PHY interface module can be imple- 
mented in the MAC controller 300 to handle the MM in- 
terface or enhanced Mil interface underneath. If the 
PHY is completely implemented together with the MAC 
in the MAC controller (such as a DSP engine) the differ- 
ence between this configuration and the hardware Mil 
interface is hidden within the MAC/PHY interface mod- 
ule. 

[0032] The Host/MAC Interface 305 is defined and 
supported by the underlying hardware bus interface. 
The hardware bus interface supports master/slave bus 
modes, enables data frames stored in host bus memory 
to be moved directly into MAC controller buffer memory 
or FIFO (DMA), enables control and status information 
exchanges between host and MAC controller 300 and 
enables event alerts (such as interrupts) between host 
and MAC controller 300. 

[0033] A data communication protocol across the 
Host/MAC Interface 305 is used to provide general pur- 
pose data frame exchanges between the host and MAC 
controller. This protocol is referred to herein as Queue 



Manager Protocol. The Queue Manager Protocol pro- 
vides a standard access method between the MAC and 
host, hiding the hardware interface underneath the 
Host/MAC Interface 305. The Queue Manager Protocol 

5 is implemented by respective software modules on both 
host side and MAC controller side to communicate 
based on Queue Manager data structures. 
[0034] The Queue Manager protocol includes the fol- 
lowing components: Queue Descriptor, Data Buffer and 

10 Frame. Figure 4 illustrates a Queue Descriptor 41 0 and 
associated Data Buffer 420 in accordance with an em- 
bodiment of the present invention. The Queue Descrip- 
tor 410 is a data structure in host memory that is com- 
posed of pointers to the Data Buffers 420. It includes 

15 information about the location of a frame and frame size. 
One Queue Descriptor can represent only one frame, 
but it can be linked to form a data queue that represents 
multiple frames. 

[0035] The Data Buffer 420 is an allocated area in 
20 host memory where a frame fragment is located. The 
Data Buffer 420 serves as a location to where the MAC 
controller 300 can DMA a received frame and from 
where the MAC controller 300 can DMA a frame to be 
transmitted. A Data Buffer 420 can store a whole frame 
25 or part of the frame. It preferably does not hold more 
than one frame. The Queue Descriptor 41 0 can point to 
one or more Data Buffers 420 for the frame(s) associat- 
ed with those Data Buffers. 

[0036] A Frame represents the data that is to be trans- 
30 mitted on the network. The frame format is defined 
based on a specific application. 

[0037] Queue descriptors can be linked together by 
setting the forward pointer 430 in the first field of the 
Queue Descriptor 410 to indicate a transmit or receive 

35 queue. The queue allows the MAC controller 300 to 
process more than one frame without a separate trans- 
mit/receive command for each frame. The host can keep 
transmit and receive queues continuously open by free- 
ing up buffers and re-linking queue descriptors faster 

40 than frames are transmitted. This is an important aspect 
in receive operations where the receive queue must be 
open continuously to avoid losing frames from the net- 
work. 

[0038] The Forward Pointer 430 is a 4 bit field which 
45 contains a pointer to the next queue descriptor in the 
same queue. There maybe some address limit on the 
start of a queue descriptor. When the pointer is 0, the 
current queue descriptor is the last one in the queue. 
When the. last queue descriptor is processed, an event 
50 alert is raised for the queue. 

[0039] The FrameStat 440 and FrameSize 450 fields 
are each 2 bits. The FrameStat 440 field is written by 
the host when a queue descriptor is created. It is over- 
written by the MAC controller 300 to report the frame 
55 completion status. The bit definitions of the FrameStat 
440 field are application specific. The FrameSize 450 
field indicates the number of bytes in the frame de- 
scribed by the queue descriptor 410. For transmitting, 
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this field is written by the host to represent the actual 
frame size to be transmitted. For receiving, the Frame- 
Size 450 field is written by the MAC controller 300 upon 
the completion of the frame reception. 
[0040] The Data Count 460 Field, is four bits and in- 
dicates the maximum number of frame data bytes stored 
or to be stored in the data buffer 420. For receiving, it is 
initially written by the host with the data buffer size, and 
overwritten by the MAC controller 300 with the actual 
data byte counts upon completion of the data fragment 
reception. The total number of the data count will equal 
the frame size. A data count of 0 indicates the end of 
data fragments in one frame. 

[0041] The Data Buffer Address field 470 is four bits 
which defines a pointer to a fragment of the frame data 
stored in data buffer 420. 

[0042] Referring now to Figure 5 there is illustrated a 
control signal exchange by the host 510 and MAC 520 
controller which support the aforementioned Queue 
Manager Protocol. The following signals are passed 
from the host 510 to the MAC 520 controller in an ex- 
emplary embodiment: QstartAddr - the start address of 
the first queue descriptor in a queue, which is the linked 
list of queue descriptors. Each time the queue descriptor 
link list is relinked for the usage of the recycled data buff- 
ers, the new start address is passed to the MAC con- 
troller 520; Qcontrol - includes some control information 
that is application specific; QlazyNotify - indicates the 
number of frames needed to be processed before an 
event alert is raised from MAC controller 520 to host 
510; and QnotifyTimeout indicates the time outvalue in 
bus cycles that an expected event alert was not received 
by the host 510. 

[0043] Additionally, to support the Queue Manager 
Protocol operation, the Queue Manager module on the 
MAC controller side supports the following event slerts 
in an exemplary embodiment: FrameProcessedAlert - 
indicates that a frame or multiple frames has been proc- 
essed by the MAC controller 520; EndOQueueAlertin- 
dicates that an end of queue condition has been met; 
Q notify TimeOutAlert- indicates that a specified time out 
value has been met; and AppSpecificAlert - indicates 
other application specific alerts. 
[0044] Undermost cases onetransmit queue and one 
receive queue are used for Queue Manager implemen- 
tations. In other embodiments, multiple transmit queues 
based on frame data priorities are supported based on 
the requirements of a specific application. 
[0045] In some embodiments, some of the soft MAC 
modules can be moved from the MAC controller 300 to 
other processors or implemented in hardware acceler- 
ators or circuits. In one embodiment, each soft MAC 
module implements thefollowing exemplary Application 
Programming Interfaces (APIs) to allow easy Inter-MAC 
communication implementations: 

SMAC_Read(); 
SMAC_Write(); 



SMAC_IOHandler(); 
SMAC_CmdHandler(); and 
SMAC_StatHandler() . 

5 [0046] The SMAC_Read() and SMAC_Write() APIs 
are used for block data communication among soft MAC 
modules both synchronously and asynchronously. 
SMAC_IOHandler() is called to handle the asynchro- 
nous data communication. SMAC_CmdHandler() han- 
dles command queuing among different modules. A 
command code is used for pass module specific com- 
mands. SMAC_StatHandler() is used for processing the 
status queue received from other modules and includes 
processing specific alerts from other modules. When 
two soft MAC modules are implemented in different 
processors, these APIs can be implemented based on 
the specific kind of inter-processor communication plat- 
forms supported. If one module is implemented in a 
hardware accelerator, these APIs can be implemented 
in a pseudo module that drives the hardware accelera- 
tor. 

[0047] Referring now to Figure 6 there is illustrated a 
HomePNA digital chip set 600 utilizing an enhanced MM, 
in accordance with the present invention, for embodi- 
ments in which MAC operating functions and PHY layer 
digital signal processing functions are implemented in a 
single processor. The chip set 600 includes a DSP core 
610 and a physical layer transceiver ASIC 620. The DSP 
core 61 0 includes a MAC module 630 and a DSP module 
640. The MAC module 630 and the DSP module 640 are 
in communication with the ASIC 620 through two individ- 
ual interfaces: MAC/PHY interface 650; and DSP/PHY 
interface 660. These two interfaces are logically sepa- 
rated but can share the same hardware components, if 
necessary, during implementation. 
[0048] The purpose of the MAC/PHY interface 650 is 
to provide a Media Independent Interface (Mil) type in- 
terconnection between the MAC module 630 and the 
PHY layer, and the purpose of the DSP/PHY interface is 
to provide an inter-communication channel between the 
DSP module 640 and the PHY layer, in which part of the 
PHY layerdigital signal processing is implemented in the 
DSP module. The following described MAC/PHY Mil 
type interconnection can also be used for implementa- 
tion in which the MAC and PHY are implemented in hard- 
wired circuits. 

[0049] The MAC/PHY interface 650 has the following 
characteristics in some embodiments: data transmis- 
sions between the MAC module 630 and the ASIC 620 
are synchronous to a clock reference at 32Mhz for data 
transfer at up to 32 Mbps; independent eight bit wide 
transmit and receive data paths; and a simple PHY man- 
agement interface that can be accessed by both a MAC 
and a host controller. 

[0050] Referring now to Figure 7 there is shown an 
interface signal exchange between the MAC 705 portion 
and the PHY 710 portion of the HomePNA digital chip 
set 600 in accordance with an exemplary embodiment 
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of the present invention. The transmit data bits 
(TXD7-TXDO) are driven by the MAC 705. TxD7-TxDO 
transition synchronously with respect to the Clk. For 
each period of the Clk when both tile Transmit On (Tx- 
ON) and Transmit Enable (TxEn) signals are averted, 
TxD7-TxDO are valid and available to the PHY 71 0. The 
TxD7-TxDO signals remain unchanged until the TxEn 
signal is asserted. While TxON or TxEn is de-asserted, 
TxD7-TxDO has no effect upon the PHY 710. TxD7 is 
the most significant bit (MSB) and TxDO is the least sig- 
nificant bit (LSB). The TxD7-TxDO bits are extended 
from MM interface bits TxD3-TxDO into an eight bit data 
bus for the purpose of the data direct memory access 
(DMA) from the DSP. 

[0051] The TxON signal is used for two purposes: 
transmit frame and transmit backoff signal. This signal 
has been modified from a Mil interface to accommodate 
the HomePNA backoff signals after collision. Regarding 
transmit frame, TxON indicates that the MAC 705 is pre- 
senting a frame on TxD7-TxDO for transmission. It is 
asserted by the MAC 705 synchronously with the first 
byte of a Frame Control field of a HomePNA 2.0 frame 
and remains asserted while all the bytes being transmit- 
ted are presented to the PHY 710. When TxON is as- 
serted, the PHY 710 uses the TxEn signal to indicate 
that TxD7-TxDO are valid with a new data byte. For 
HomePNA systems, the PHY 710 transmits a frame pre- 
pended with PEAMBLE64 to the wire. PREAMBLE64 is 
a HomePNA PHY layerframing header known in the art. 
The PHY 710 continues to transmit until TxON is de- 
asserted. The PHY 710 ends transmission with EOF. 
Preferably, TxON is asserted for at least 92.5u,s 
(TX_FRAME). Figure 8 shows the relative timing of the 
TxON signal in relation to a frame transmission with no 
collisions. 

[0052] Referring back to Figure 7. a Backoff Signal 
Slot On (BkOn) is used by the MAC 705 to indicate the 
start of a backoff signal slot. The PHY 71 0 uses the as- 
sertion of the BkOn signal as a directive to begin moni- 
toring the wire for any backoff signal received on the 
wire. The duration of BkON is 3x32 \xs = 96 |as in one 
embodiment. While BkON signal is asserted, TxON as- 
sertion means that the MAC 705 requests the PHY 710 
to apply one backoff signal to the wire. From the time 
TxON is asserted while BkON is asserted, the PHY 710 
applies the backoff signal within, for example, a 2 (is 
limit. 

[0053] A 1 .0 Mode On (TxV1M1) assertion indicates 
that an HPNA 1.0 frame is being transmitted on 
TxD7-TxDO during TxON assertion. TxVIMI remains as- 
serted during the entire period of frame transmission. 
The TxVIMI signal is a new signal on top of a Mil inter- 
face. 

[0054] The reference clock (Clk) is a continuous clock 
locked, for example, at 32 MHz and is sourced by the 
PHY 71 0. The Clk provides the timing reference for the 
TxON, TxEn, and TxD7-TxDO signals for data transmis- 
sion from the MAC 705 to the PHY 710. The Clk also 



provides the timing reference for the transfer of RxON , 
RxEn, and RxD7-RxDO signals for data transmission 
from the PHY 710 to the MAC 705. 
[0055] The receive bits RxD7-RxDO signals transition 
5 synchronously with respect to the Clk signal. RxD7-Rx- 
DO are driven by the PHY 710. For each Clk pericd in 
which both RxON and RxEn are asserted, RxD7-RxDO 
provides eight valid bits of decoded data from the PHY 
710 to the MAC 705. RxD7-R-xDO remain valid until a 
10 Receive Enable (RxEn) signal is asserted. While Re- 
ceive Data On (RxON) or RxEn is de-asserted. 
RxD7-RxDO are invalid. RxD7 is the most significant bit 
(MSB) and RxDO is the least significant bit (LSB) . The 
KxD7-RaDC bits are extended from Mil interface bits 
15 RxD3-RxD0 into an eight bit data bus forthe purpose of 
the data direct memory access (DMA) to the DSP. 
[0056] The RxON signal is used for two purposes: re- 
ceive Frame and receive backoff signal. The use of this 
signal has been modified from a M 1 1 interface to accom- 
20 modate the HomePNA backoff signals after collision, 
For frame receiving, the RxON is provided by the PHY 
71 0 to indicate that the PHY 71 0 has valid decoded data 
bits on RxD7-RxDO. The data on the RxD7-RxDO is 
synchronous to the Clk and RxON transitions synchro- 
's nously with respect to the Clk. Further, RxON remains 
asserted continuously from the first decoded bit of a 
frame (without preamble) through the final bit of the 
frame (without EOF) and is negated prior to the first Clk 
cycle that follows the final nibble. Upon RxON assertion, 
30 the PHY 71 0 starts sending the RxEn signal which indi- 
cates that a valid data byte is present on RxD7-RxDO. 
Figure 9 shows the relative timing of RxON during a 
frame reception. 

[0057] Referring back to Figure 7, the RxON signal is 
35 also used by the PHY 71 0 to indicate that a backoff sig- 
nal has been received while BkON is asserted by the 
MAC 705. The latency between the backoff signal ap- 
pearing on the wire and the RxON being asserted is ap- 
proximately 1 0jas=5. The 5 is the minimum backoff sig- 
40 nal decoding time. RxON signal remains asserted until 
the end of the current signal slot (32 \is) . 
[0058] The TxEn signal is sourced by the PHY 71 0 to 
signal the MAC 705 to place new data on TxD7-TxDO. 
Once TxON is asserted, the PHY 710 provides TxEn 
45 pulses (one pulse is 1/32M Hz cycle wide) to indicate that 
the MAC 705 can place new valid data on TxD7-TxDO. 
The average rate of the TxEn pulses is the transmission 
data rate in bytes, which is abour 4MHz for a 32Mbps 
data rate. This signal provides for transmitting data be- 
so tween the MAC 705 and the PHY 71 0 at a variable rate 
which matches the PHY's data rate. Upon de-assertion 
of the TxON signal, the PHY 710 stops supplying TxEn 
pulses. The TxEn signal timing during a data transmis- 
sion from the MAC 705 to the PHY 71 0 is shown in Fig- 
55 ure 8. 

[0059] Referring back to Figure 7, the RxEn signal is 
sourced by the PHY 71 0 to signal the MAC 705 that new 
data has been placed on RxD7-RxDO signal lines. The 
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RxEn signal is only valid while the RxON signal is as- 
serted. The average rate of the RxEn signal pulses will 
be the transmission data rate in bytes, which is around 
4MHz for a 32Mbps data rate. This signal provides for 
transmitting data betweei MAC 705 and PHY 710 at a 
variable rate to match the PHY's data rate. RxEn signal 
operation during data transmission from the PHY 71 0 to 
the MAC 705 is shown in Figure 9. 
[0060] The Carrier Sense (CS) signal is asserted by 
the PHY 71 0 when either transmit or receive medium is 
non-Idle and CS is de-asserted by the PHY 710 when 
both transmit and receive media are idle. The PHY in- 
sures that the CS signal remains asserted throughout 
the duration cf a collision condition. The CS is not re- 
quired to transition synchronously with respect to the 
Clk. The MAC 705 uses this signal to accomplish the 
"deference" procedure. Further the CS is not asserted 
when line noise is detected on the wire. Figure 8 depicts 
the behavior of CS during frame transmission without a 
collision, while Figure 10 shows the behavior of CS dur- 
ing a frame transmission with a collision. 
[0061] A Collision Detected signal (CD) is asserted by 
the PHY 71 0 upon detection of a collision on both trans- 
mit and receive media, and remains asserted while the 
collision condition persists. The CD is not required to 
transition synchronously with respect to the Clk signal 
and it remains asserted for at least 32 jis (CD_MIN). 
Figure 1 0 shows the relative timing of CD during a frame 
transmission with a collision. 

[0062] A Receive Error signal (RxErr) is generated by 
the PHY 71 0 and is asserted for one or more Clk periods 
to indicate to the MAC 705 that an error (e.g. a coding 
error, or any error detected by the PHY 710 that may 
otherwise be undetectable at the MAC layer) was de- 
tected in the frame presently being transferred from the 
PHY 710 to the MAC 705. RxErr transitions synchro- 
nously with respect to the Clk. While RxON is de-assert- 
ed, RxErr is treated as invalid. Figure 1 1 shows the rel- 
ative timing of RxErr during the reception of a frame with 
errors. 

[0063] A Receive HPNA 1 .0 Frame (RxVIMI) signal is 
provided by the PHY 705 to indicate a detection of a 
HPNA 1 .0 frame. This signal is asserted during the en- 
tire period of RxON signal assertion if the data on 
RxD7-RxDO is a HPNA 1 .0 frame. 
[0064] A MAC controller associated with the MAC lay- 
er can access and control the aforementroned signaling 
interface through a list of 1 6-bit memory mapped regis- 
ters. Inside the register set, some registers are imple- 
mented in the MAC and some are implemented in the 
PHY layer. The registers accessible by the MAC 705 are 
listed in the table shown in Figure 12. 
[0065] Referring to Figure 1 2, the Tx Address register 
(register 0) is used by the MAC 705 to specify the start- 
ing address of its frame buffer, which is used to store 
the frame to be transmitted to the PHY 71 0. Before the 
TxON signal is asserted by the MAC 705, the Tx Ad- 
dress register will contain a valid frame buffer start ad- 



dress. The content of this register does not change until 
updated by the MAC 705. 

[0066] The Tx Length register (register 1) is used by 
the MAC 705 to specify the number of octets of the frame 
5 data stored in the frame buffer to be transferred to the 
PHY 71 0. Before TxON signal is asserted, the Tx length 
register will contain the valid frame length to be trans- 
ferred to the PHY 710. The content of this register will 
not change until updated by the MAC 705. 
[0067] The Rx Address register (register 2) is used by 
the MAC 705 to specify the starting address of its re- 
ceive frame buffer which stores the frame data to be 
transferred from the PHY 710. Before RxON signal is 
asserted, the Rx Address register will contain the valid 
receive frame buffer start address. The content of this 
register will not change until updated by the MAC 705. 
[0068] The Rx Length register (register 3) is used by 
the MAC 705 to get the number of octets of frame data 
that have been transferred and stored in MAC'S receive 
frame buffer. After the RxON signal is de-asserted, the 
Rx Length register will contain the final number of octets 
in the receive frame buffer that contains the valid frame 
data. The content of this register will not change until 
the next frame receiving process is finished. 
[0069] The Control register (register 4) is used by the 
MAC 705 to control the signals going from the MAC 705 
to the PHY 710. The assignment of bits in the Control 
register are listed in the table shown in Figure 13. 
[0070] The Status register (register 5) is used by the 
MAC 705 to receive the status information for signals 
sent from the PHY 71 0 to the MAC 705. The assignment 
of bits in the status register are listed in the table shown 
in Figure 14. 

[0071] The Interrupt Mask register (register 6) is used 
by both the MAC and other modules residing in a DSP 
to selectively enable the delivery of interrupts from the 
PHY layer. The enables in this register do not affect the 
recording of interrupt conditions in the Interrupt Status 
register. The interrupts are delivered when both the spe- 
cific mask bit is set and the Global Interrupt Enable is 
set in the Control register. The assignment of bits in the 
interrupt Mask register are listed in the table shown in 
Figure. 15. 

[0072] The Interrupt Status register (register 7) con- 
tains the status of the PHY 71 0 interrupt sources. A bit 
set in this register indicates that an interrupt has been 
generated. The actual interrupt signal is not asserted to 
the MAC 705 unless the corresponding enable bit is set 
to "1 " in the Interrupt Mask register and the Global In- 
terrupt Enable bit is set in the Control Register. Reading 
this register will clear all the bits in the register. This reg- 
ister has the value "0" at PHY reset. The assignment of 
bits in the Interrupt Status register are listed in the table 
shown in Figure 1 6. 

[0073] The CRC 32 registers (register 8 and 9) are 
used to store the high and low 1 6 bits of CRC32 calcu- 
lated by the PHY 710 for the frame received. The con- 
tents of these two registers are valid immediately after 
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the transition of the RxON signal from asserted to de- 
asserted. The MAC 705 then compares the PHY-calcu- 
latedCRC32 with the one in the received frame for error 
checking. 

[0074] The CRC16 register (register 10) is used to 
store the CRC 16 calculated by the PHY 710 for a re- 
ceived HPNA 2.0 frame. The content of this register is 
valid immediately after the transition of RxON signal 
from asserted to de-asserted. The MAC 705 then com- 
pares the PHY-calculated CRC1 6 with the one in the re- 
ceived frame for error checking. 
[0075] Besides the signaling interface between MAC 
705 and PHY 71 0, a general purpose PHY management 
interface is defined to control the PHY and gather status 
information from the PHY 71 0 not only by the MAC 705 
but also by a host controller associated with the MAC 
705 on which a PHY management entity may reside. 
Two general purpose PHY management registers (reg- 
ister 11 and register 12) are defined for this purpose. 
The main difference between the General Purpose PHY 
Management registers and the registers defined above 
is that both the DSP core and an external host controller 
can access these PHY management registers. The ta- 
ble shown in Figure 1 7 defines the general purpose PHY 
management control register (register 1 1 ) and the table 
shown in Figure 1 8 defines the PHY management status 
register (register 12). 

[0076] The aforementioned signaling interface be- 
tween the PHY 71 0 and MAC 705 is controllablethrough 
a list of 1 6-bit registers accessible by the PHY 71 0. The 
registers are listed in the table shown in Figure 19. All 
the registers are implemented in the PHY 71 0. However, 
some of them are accessible by the MAC 705. Some of 
the registers defined in Figure 19 are the same as in 
Figure 12. 

[0077] The TxFrame Length register (register 0) of 
Figure 1 9 is the same register as register 1 of Figure 1 2 
and the RxFrame Length register (register 1) of Figure 
1 9 is the same register as register 3 of Figure 12. 
[0078] The signal control register (register 2) of Figure 
19 is used by the PHY 71 0 to control the signals going 
from the PHY 71 0 to the MAC 705. The assignment of 
bits in the Signal Control Register is listed in the cable 
shown in Figure 20. 

[0079] The Signal status register (register 3) of Figure 
19 is the same register as register 5 of Figure 12 and 
the CRC32 registers (register 4 and 5) of Figure 1 9 are 
the same registers as register 8 and register 9 of Figure 
1 2. The PHY 71 0 calculates the CRC32 for the received 
frame and stores the results in these two registers. 
[0080] The CRC1 6 register (register 6) of Figure 1 9 is 
the same register as register 10 of Figure 12. The PHY 
calculates the CRC 1 6 forthe received frame and stores 
the result in this register. 

[0081] The PHY management registers (register 7 
and 8) of Figure 19 are the same registers as register 
11 and 12 of Figure 12. 

[0082] Referring back to Figure 6 ; the DSP core 610 



can also be used to accomplish some of the program- 
mable PHY layer digital signal processing functions. 
The DSP module 640 is used forth is purpose. A logically 
separate interface, the DSP/PHY interface 660 is de- 
5 fined for the data communications between the DSP 
module 640 and the PHY 620. The data transmitted from 
the PHY 620 to the DSP module 640 can include 
HomePNA sample data acquired through an HomePNA 
Analog Front End (AFE). The data transmitted from the 
10 DSP module 640 to the PHY 620 can include desired 
PHY layer DSP processing results. Since the DSP/PHY 
interface 660 access is mutually exclusive with respect 
to the MAC/PHY interface 650 access, some of the in- 
terface hardware components, such as a DMA control- 
's |er, interrupt line, etc. ; can be shared between the two 
interfaces. 

[0083] Some embodiments of the DS P/PHY interface 
660 include the following exemplary characteristics: up 
to an 8MHz sample rate for sample data transfer from 

20 the PHY 620 to the DSP module 640; data transmis- 
sions from the DSP module 640 to the PHY 620 through 
a general purpose DSP memory mapped interface to 
the PHY registers or FIFO; independent 16-bit wide 
transmit data paths from the PHY 620 to the DSP 640; 

25 and a debug interface that can be accessed by both the 
DSP core 61 0 and a host controller associated with the 
MAC module 630. 

[0084] Exemplary DSP/PHY interface signals used 
for sample data transfer from the PHY 620 to the DSP 

30 module 640 include: SampOn, SampEn, 
SampD15-SampD0. The SampON signal is used to 
transmit a block of sample data from the PHY 620 to the 
DSP module 640. The SampON signal is provided by 
the PHY 620 to indicate that the PHY 620 has valid sam- 

35 pie data bits on SampDI5-SampDO, SampON remains 
asserted continuously from the first word of a block of 
sample data through the final word of the block of sam- 
ple data. Upon SampON assertion, the PHY 620 starts 
sending the SampEn signal which indicates that a valid 

40 sample word is present on SampDI5-SampDO. The 
SampEn signal is sourced by the PHY 620 to signal the 
DSP module 640 that new sample data has been placed 
on SampDI5-SampDO signal lines. The average rate of 
the SampEn signal pulses is the transmission sample 

45 rate, which can be, for example, around 8MHz. The 
SampD15-SampDO signals transition synchronously 
with the SampEn signal pulses. SampDI 5-SampDO are 
driven by the PHY 620. For each period of SampEn as- 
serted, SampDI 5-SampDO provides sixteen valid sam- 

50 pie data bits from the PHY 620 to the DSP module 640. 
[0085] The DSP/PHY interface can be accessed and 
controlled through a list of 16-bit memory mapped reg- 
isters by the DSP module 640. Some of the registers 
are implemented in the DSP module 640 and some of 

55 them are implemented in the PHY 620. The DSP acces- 
sible registers are defined by the table shown in Figure 
21. 

[0086] Referring to Figure 21 , using the Sample data 
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address register (register 0), the DSP module 640 writes 
the start address of the buffer which stores the sample 
data coming from the PHY 620. This register is set be- 
fore the sample data is transferred from the PHY 620. 
Using the sample data length register (register 1), the 
DSP module 640 writes the sample data length it ex- 
pects. 

[0087] After a block of sample has been transferred 
from the PHY 620 to the DSP module 640 memory, the 
Rx Sample Data Length Register (register 2) stores the 
actual amount of sample data, in a 1 6-bit word, that has 
seen transferred from the PHY 620. This is a DSP read- 
only register. 

[0088] The DSP data length register (register 3) is 
used to store the amount of data, in 16-bit words, for 
DSP processed results that will be transferred to the 
PHY 620. It is written before the DSP module 640 starts 
to write the actual data into the DSP Data Port Register 
(register 4). 

[0089] The DSP data port register (register 4) is used 
by the DSP module 640 to write the PHY layer DSP 
processing results to the PHY 620. The number of data 
words in one burst write is stored in the DSP data length 
register 3. 

[0090] The aforementioned DSP/PHY interface 660 
(Figure 6) can also be accessed and controlled through 
a list of 1 6-bit registers and FIFO accessible by the PHY 
620. Some registers are implemented in the DSP mod- 
ule 640 and some of them are implemented in the PHY 
620. The registers defined below are accessible by the 
PHY 620. Some of the registers are the same as listed 
in the table shown in Figure 21. Figure 22 shows the 
registers accessible for reading and/or writing by the 
PHY 620. 

[0091] The Rx sample data length register (resisterO) 
and DSP data length register (register 1) of Figure 22 
are the same as register 2 and register 3, respectively, 
of Figure 21 . 

[0092] The DSP data port register (register 2) is used 
by the PHY to read the DSP processing. The number of 
data words in one block write is stored in the DSP data 
length register (register 1). 

[0093] Referring now to Figure 23 there are shown 
four exemplary types of MAC architecture configura- 
tions implementing the modulized soft MAC in accord- 
ance with the present invention. In the first implementa- 
tion the soft MAC is implemented in a single dedicated 
reduced instruction set controller (RISC) machine 2602 
with the PHY layer implemented in both hardware 2604 
and a digital signal processor (DSP) 2606. 
[0094] The soft MAC modules are implemented within 
the RISC 2602 which also includes a host interface soft- 
ware module 2608 and a RISC/DSP interface software 
module 2610. Additionally, a PHY interface software 
module 2612 is implemented in the DSP 2606. Thus, 
the soft MAC modules and the programmable portions 
of the PHY layer are implemented in separate proces- 
sors. 



[0095] The second implementation illustrates that 
both the soft MAC modules and the programmable por- 
tions of the PHY layer are implemented in a single DSP 
2620 where the remaining PHY portions are implement- 
5 ed in a hardware ASIC 2622. In this implementation, a 
host interface software module 2624 and a PHY inter- 
face software module 2626 are also implemented in the 
DSP 2620. 

[0096] In the third implementation, MAC software 
10 modules, denoted MACx and MACy, have been split be- 
tween the host processor 2630 and a DSP 2632. In this 
application, a host interface software module 2634 is im- 
plemented in the host processor 2630, and a MACx/MA- 
Cy interface software module 2636 and PHY interface 
15 software module 2638 are implemented in the DSP 
2632. 

[0097] In the fourth implementation, all the MAC and 
PHY layer functions are implemented in a single DSP 
2640 in which the host interface software module 2644 
20 and the PHY interface software module 2648 are also 
implemented. 

[0098] Another implementation of the present inven- 
tion enables the co-existence of multiple standard de- 
fine M ACs in a single device for home network type ap- 

25 plication. One example is the 802.11 Wireless LAN 
when an associated Distribution System is composed 
of an Ethernet or HomePNA as its backbone and a por- 
tal/gateway device is used to connect the 802.11 LAN 
into the backbone. The portal device must contain mul- 

30 tiple MACs (HomePNA with 802.11 or Ethernet with 
802.11) to access multiple PHYs. In a multiple MAC de- 
vice, a programmable MAC architecture allows multiple 
MACs to be easily implemented and integrated into a 
single device without having multiple MAC components 

35 which are each dedicated to only a single MAC type 
standard, thus, saving development time and cost. 
[0099] Another application example is the implemen- 
tation of the HomePNA 2.0 MAC. As stated before, the 
HomePNA 2.0 has, two kinds of MAC architectures: the 

40 monolithic single MAC architecture and a two-layer 
MAC architecture that are inter-connected through the 
Media Independent Interface (Mil) as illustrated in Fig- 
ure 24. In the first demonstrated architecture, it is pos- 
sible that the application requires the HomePNA 1.0 

45 MAC being implemented in a separate processor such 
as a host controller or even hardware versus the 
HomePNA 2.0 enhanced part of the MAC (EMAC) being 
implemented in a programmable MAC controller. Under 
this application, it is very critical that a programmable 

50 MAC architecture is designed to allow MAC functions 
distributable among multiple processors or split be- 
tween hardware and software without major modifica- 
tions of the architecture. 

[01 00] Although a preferred embodiment of the meth- 
55 od and system of the present invention has been illus- 
trated in the accompanied drawings and described in 
the foregoing Detailed Description, it is understood that 
the invention is not limited to the embodiments dis- 
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closed, but is capable of numerous rearrangements, 
modifications, and substitutions without departing from 
the spirit of the invention as set forth and defined by the 
following claims. 



Claims 

1 . An apparatus for implementing a media access con- 
trol layer in an open system interconnection type 
network, comprising: 

a plurality of operating modules each enabling 
a respective media access control layer oper- 
ating function, wherein each of said plurality of 
operating modules is software - programmable 
for enabling said operating module to perform 
its associated media access control layer oper- 
ating function in accordance with a plurality of 
communication standards; 
a host interface module configured to enable 
communication between a host processor and 
said media access control layer; 
a physical layer interface module configured to 
enable communication between a physical lay- 
er and said media the a access control layer; 
and 

an inter-module communication interface ena- 
bling communication between said plurality of 
operating modules. 

2. The apparatus of Claim 1 , further for implementing 
a portion of said physical layer, including a further 
operating module for performing a physical layer 
operating function. 

3. The system of Claim 2, wherein said further oper- 
ating module is a software-programmable module 
for performing a digital signal processing function. 

4. The system of Claim 3. wherein said physical layer 
interface is further configured to enable communi- 
cation between said further operating module a re- 
mainder of said physical layer. 

5. The system of Claim 1 , wherein said host interface 
module and at least one of said operating modules 
are implemented together in a digital signal proces- 
sor. 

6. The system of Claim 1 , wherein said host interface 
module supports a data communication protocol for 
enabling data frame transmission, said data com- 
munication protocol comprising: 

a descriptor implemented in memory associat- 
ed with said host processorfor indicating frame 
location and size, said descriptor represents a 



first frame and is further linkableto an addition- 
al descriptor to form a data queue that repre- 
sents a plurality of frames; and 
a data buffer implemented in memory associat- 
5 ed with said host processor for storing frame 

data. 

7. The system of Claim 1 , wherein at least one of said 
operating modules is implemented in a digital signal 

10 processor. 

8. The system of Claim 7, wherein at least another one 
of said operating modules is implemented in a sec- 
ond processor. 

15 

9. The system of Claim 8, wherein said second proc- 
essor is said host processor. 

10. The system of Claim 1 further comprising: 

20 

a hardware accelerator for implementing at 
least one media access control layer operating 
function; and 

said hardware acceleratorcoupled to said inter- 
ns module communication interface. 

1 1 . The system of Claim 1 , wherein said plurality of op- 
erating modules comprises a transmitter module, 
receiver module, deference algorithm module, sta- 

30 tistics maintenance module and utility module. 

1 2. A method for implementing a media access control 
layer in an open system interconnection type net- 
work, comprising: 

35 

separating media access control layer operat- 
ing functions into plurality of corresponding 
software - programmable operating modules; 
and 

40 programming each of said operating modules 

to perform its corresponding media access con- 
trol layer operating function in accordance with 
a plurality of communication standards. 

45 13. The method of Claim 12 further comprising: 

implementing a further media access control 
layer operating function in a hardware accelerator. 

14. The method of Claim 12 further comprising imple- 
50 menting at least a portion of said operating modules 

together in a digital signal processor. 

15. The method of Claim 14 further comprising imple- 
menting a second portion of said operating modules 

55 in a separate processor. 

16. The method of Claim 15, wherein said separate 
processor is a host processor that uses said media 
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access control layer. 

17. The method of Claim 12, including providing soft- 
ware-based host and physical layer interface mod- 
ules for enabling communication between a host 
processor and said media access control layer and 
between a physical layer and said media access 
control layer, respectively 

The method of Claim 17 further comprising sepa- 
rating said physical layer into first and second por- 
tions, wherein said first portion is implemented in a 
further software-programmable operating module 
for performing a physical layer operating function. 

18. The method of Claim 18 further comprising imple- 
menting said further operating module and at least 
a portion of the remaining operating modules to- 
gether in a digital signal processor. 

19. The method of Claim 17 further comprising imple- 
menting said physical layer interface module in a 
digital signal processortogether with one of said op- 
erating modules. 

20. The method of Claim 17 further comprising imple- 
menting said host and physical layer interface mod- 
ules in a digital signal processortogether with one 
of said operating modules. 

21. The method of Claim 12. including providing an in- 
ter-module programming interface enabling com- 
munication between said plurality of individual op- 
erating modules. 

22. The method of Claim 22, including said host inter- 
face module maintaining in memory a plurality of 
descriptors for indicating frame location and size of 
communication data frames, and linking the de- 
scriptors to form a queue that represents a plurality 
of communication data frames. 

23. A system for interfacing in an open system intercon- 
nection type network, said system comprising: 

a media access control layer configured to 
manage data flow over said open system inter- 
connection type network; 
a physical layer configured to code data for 
transmission to a medium; 
an eight bit transmit data bus configured to en- 
able data transfer from said media access con- 
trol layer to said physical layer, wherein said 
eight bit transmit data bus is driven by said me- 
dia access control layer; 
an eight bit receive data bus configured to en- 
able data transfer from said physical layer to 
said media access control layer, wherein said 
eight bit receive data bus is driven by said phys- 



ical layer; 

a transmit ON signal bus configured to indicate 
to said physical layer that a data frame is avail- 
able on said eight bit transmit data bus and to 
5 indicate a request by said media access control 

layer for said physical layer to apply a backoff 
signal; and 

a receive ON signal bus configured to indicate 
that to said media access layer valid data is 
10 available on said eight bit receive data bus and 

to indicate that a backoff signal request is re- 
ceived. 

24. The system of Claim 24, wherein said eight bit 
15 transmit data bus is further configured to enable di- 
rect memory access (DMA) from a digital signal 
processor (DSP), wherein said DSP implements a 
programmable digital signal processing function of 
said physical layer. 

20 

25. The system of Claim 24, wherein said eight bit re- 
ceive data bus is further configured to enable direct 
memory access (DMA) to a digital signal processor 
(DSP), wherein said DSP implements a program- 
's mable digital signal processing function of said 

physical layer. 

26. The system of Claim 24, wherein said media access 
control layer request said backoff signal upon de- 

30 tection of a collision condition. 

27. The system of Claim 24 further comprising a trans- 
mit HPNA mode signal bus configured to indicate 
that a HPNA 1.0 type data frame is available for 

35 transmission on said eight bit transmit data bus. 

28. Thesystem of Claim 24further comprising a receive 
HPNA mode signal bus configured to indicate that 
a HPNA 1 .0 type data frame is available for trans- 

40 mission on said eight bit receive data bus. 

29. The system of Claim. 24, wherein said backoff sig- 
nal comprises a HPNA type backoff signal. 

45 30. The system of Claim 24 further comprising a regis- 
ter set configured for managing data signal ex- 
change between said media access control layer 
and physical layer. 

50 31. The system of Claim 31 , wherein a first portion of 
said register set is implemented in said media ac- 
cess control layer and a second portion of said reg- 
ister set is implemented in said physical layer. 

55 32. The system of Claim 24 further comprising: 

a backoff signal slot ON data bus configured to 
indicate a start of a backoff signal slot; 
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24 



a transmit enable data bus configured to indi- 
cate that a new data frame can be placed on 
said eight bit transmit data bus; 
a reference clock sourced by said physical lay- 
er; 

a carrier sense signal bus configured to indicate 
idle and non-idle conditions on transmit and re- 
ceive mediums; 

a collision detection signal bus configured to in- 
dicate a collision condition on said transmit and 
receive mediums; 

a receive error signal data bus configured to in- 
dicate an error detection in a transmit data 
frame; and 

a receive enable data bus configured to indi- 
cate placement of new data on said eight bit 
receive data bus. 

33. A media interface for data exchange between a me- 
dia access control layer and a physical layer in an 
open system interconnection layered type network, 
said media interface comprising: 

an eight bit transmit data bus configured to en- 
able data transfer from said media access con- 
trol layer to said physical layer, wherein said 
eight bit transmit data bus is driven by said me- 
dia access control layer; 
an eight bit receive data bus configured to en- 
able data transfer from said physical layer to 
said media access control layer, wherein said 
eight bit receive data bus is driven by said phys- 
ical layer; 

a transmit ON signal bus configured to indicate 
to said physical layer that a data frame is avail- 
able on said eight bit transmit data bus and to 
indicate a request by said media access control 
layer for said physical layer to apply a backoff 
signal; and 

a receive ON signal bus configured to indicate 
to said media access control layer than valid 
data is available on said eight bit receive data 
bus and to indicate that a backoff signal request 
is received. 

34. The media interface of Claim 34, wherein said eight 
bit transmit data bus is further configured to enable 
direct memory access (DMA) from a digital signal 
processor (DSP), wherein said DSP implements a 
programmable digital signal processing function of 
said physical layer. 



36. The media interface of Claim 34, wherein said me- 
dia access control layer request said backoff signal 
upon detection of a collision condition. 

5 37. The media interface of Claim 34 further comprising 
a transmit HPNA mode signal bus configured to in- 
dicate that a H PNA 1 .0 type data frame is available 
for transmission on said eight bit transmit data bus. 

10 38. The media interface of Claim 34 further comprising 
a receive HPNA mode signal bus configured to in- 
dicate that a H PNA 1 .0 type data frame is available 
for transmission on said eight bit receive data bus. 

f5 39. The media interface of Claim 34, wherein said back- 
off signal comprises a HPNA type backoff signal. 

40. The media interface of Claim 34 further comprising 
a register set configured for managing data signal 

20 exchange between said media access control layer 
and physical layer. 

41 . The media interface of Claim 41 , wherein a first por- 
tion of said register set is implemented in said media 

25 access control layer and a second portion of said 
register set is implemented in said physical layer. 

42. The media interface of Claim 34 further comprising: 

a backoff signal slot ON data bus configured to 
indicate a start of a backoff signal slot; 
a transmit enable data bus configured to indi- 
cate that a new data frame can be placed on 
said eight bit transmit data bus; 
a reference clock sourced by said physical lay- 
er; 

a carrier sense signal bus configured to indicate 
idle and non-idle conditions on transmit and re- 
ceive mediums; 

a collision detection signal bus configured to in- 
dicate a collision condition on said transmit and 
receive mediums; 

a receive error signal data bus configured to in- 
dicate an error detection in a transmit data 
frame; and 

a receive enable data bus configured to indi- 
cate placement of new data on said eight bit 
receive data bus. 



35 



40 



45 



35. The media interface of Claim 34, wherein said eight 
bit receive data bus is further configured to enable 
direct memory access (DMA) to a digital signal 55 
processor (DSP), wherein said DSP implements a 
programmable digital signal processing function of 
said physical layer. 
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